Let me explain how I came here in the first place.

While discussing removal of some deprecated features with @Thomas-Gelf he opted against removing the command pipe. He considered it faster than the Icinga 2 API for massive stuff submission. I thought: wait, we have one system which eventually does massive stuff submission via API – Icinga Web. I even actually did that while testing Icinga ack sync. And it was indeed slow. I asked myself: what could it already do by itself to do this faster? What does it do right now? While reverse-engineering this repo I came to the conclusion that it renders, sends and awaits commands one by one. I remembered that @yhabteab did somewhere something with PHP event loops and let him show me them. They could help me sending multiple commands concurrently. It turned out more complicated than I thought, but then I remembered something else. @julianbrost digged out than our API supports not only DSL filters and filter_vars which iterate over all objects. It also supports targeting a specific object by name. This repo already does this. But it supports targeting multiple specific objects by array of names as well. That's what I did here.

• Remove deprecated features: statusdata, compatlog, checkresultfilereader, commandpipe icinga2#6307
• Acknowledgement-Sync between masters are not working icinga2#9652
• Better document how to match (single) objects in API requests icinga2#9188

Now the command forms render at best exactly one Icinga 2 API action request targeting all selected objects at once, not one request per object. Commenting e.g. 500 hosts now takes 4s, not 40. For this now commands and forms always handle multiple objects by design. PHP generators everywhere don't permit the RAM to blow up. Delete*Command are now parts of the ObjectsCommand family.

TODO

• Approval of the concept in general
• Agreement on the implementation details
• What's up with GHA? (@Al2Klimov)
• Tests of all code usages of all commands DB-Web supports